Almost done. I need to implement the JsonSchema trait. Finally, because the base Node struct is now so small (currently 128 bytes), I think it no longer makes sense to box it (as we currently do using Arc).

I was previously asked to implement the builder pattern, where the setter methods look like this:

pub fn with_role(mut self, role: Role) -> Self {
    self.role = role;
    self
}

I previously rejected this because I felt it was relying too much on the optimizer to avoid copying the struct around. I also felt that, while the pattern is convenient for hand-written test and demo code, it wouldn't matter much in actual GUI toolkit implementations, and might actually be less convenient in that context. Now I've realized that I was more right with that last point than I knew. In both egui and my Druid proof-of-concept integration, the toolkit stores under-construction Node structs in a collection, and makes mutable references to those structs available for the widget implementations to populate. A move-based builder pattern is incompatible with that implementation. So I'm now sure that my initial instinct was correct. Hand-rolled tests and samples will just have to be a bit more verbose.

The change to eliminate the dependency on kurbo may seem to be over-reaching for this PR. But it's part of my plan to make AccessKit acceptable to even the most dependency-conscious projects, and I figured I should make all the planned breaking API changes in the foundational crate at once.

This is now ready for review. The impact on a real GUI toolkit can be seen in this egui branch.

@federicomenaquintero Since this is based on one of the techniques that you used to reduce memory usage in librsvg, as we previously discussed in the GNOME accessibility chat room, I'd appreciate your review.

There are two things about this branch I'm currently not happy with:

1. Lack of test coverage. I definitely want to use the serde_test crate to test the Serialize and Deserialize implementations. Some more testing of property-related code paths would also be good.
2. Mandatory use of a global variable behind a mutex in this foundational crate might not be a good idea, particularly since the mutex is locked with every individual call to NodeBuilder::build. I think I want to replace this with an explicit argument to build, and an optional convenience function to use a global instance of that struct. The Deserialize implementation will have to use the global, though.

I have permission from @DataTriny (my primary collaborator on this project) to go ahead and merge this, though it hasn't yet been fully reviewed. We agree that the change is necessary, I'm confident that the approach is fundamentally sound, and I don't want to hold up corresponding updates in downstream projects. Please open issues or PRs for any problems found in subsequent reviews of this refactor.